Documenting the Domain Modeling in Simple DSL

いったん自然言語寄りのDSLと、型、に仕様を書き下す

input/outputや副作用やイベントなどを意識する

代数的データ型を使う

クラス構造とかはガン無視

ドメインモデルをそのまま写す

細かい仕様であるvalidationなども書いていく

Documentを書いていくことで、自分の理解も増えていく

大まかなWorkflowを表現していく

p.32の上の方のは自然言語よりだが、p.40では擬似コードで書かれている

code:p.40

workflow "place order" =

input: OrderForm

output: ...

// step 1

do ValidateOrder

If order is invalid then:

add InvalidOrder to pile

stop

// step2

do PriceOrder

// step3

do SendAcknowledgementToCustomer

...

code:p32

bounder context: Order-Taking

data Order =

CustomerInfo

AND ShippingAddress

AND BillingAddress

AND list of OrderLines

値の取りうる範囲などを記述

code:p36

data WigetCode = string starting with "W" then 4 difits

code:p.37

data UnitQuantity = integer between 1 and ?

Lifecycleの記述

ValidateされたOrderと、ValidateされてないOrderみたいなものが生じる場合は、その両方ともを区別して表現しておく

code:p38, p39

data UnvalidatedOrder =

UnvalidateedCustomerInfo

AND UnvalidatedShippingAddress

...

これで、注文のlifcycle内でのOrderの状態を全て仕様化できる

document化する際に、ある値の最小値、最大値などで未定義なことに気付いたら、ドメインエキスパートに聞く

細かい値のValidationのようなもの

一つの注文の型をライフサイクルごとに定義する

一つの注文は、未検証、検証済み、決済済みの3状態があり

一つの注文はレコード型になっている

これを各段階ごとに名前を付けて、型を用意する

客が入力してから注文確定するまでの大きな注文の過程を小分けにして疑似コード化する

未検証、検証済み、決済済みのようなサブステップに分ける

各ステップでのinput/outputや、依存する外部の情報、どういうステップを踏むか、などを擬似コードで書く

大まかなworkflowは表現できるかもしれないが、細々とした機能の表現は難しくない

それはDomainModelingとちょっと意味合いがずれるのか？

この書籍内ではF#を使っているので、syntaxがじゃっかんF#に寄っているが、実装予定の言語によって、syntaxも変えていく感じなのかな

動的型付けの言語では不可能

というか代数的データ型がない言語だと厳しそう

これほんまにスケールするのか？

IDEのパワーを借りたい

スクボの場合、IDE並の補完を効かせるためにはリンクに切る必要がある

そもそも、これ、自然言語で詳細に書いていくのと比べて何が良いんだ？

p.36~